1. Field of the Invention
The present invention relates to processor flow, and more particularly to processor pipelines and methods, which provide pointer instructions ahead of instruction issuance.
2. Description of the Related Art
The demand for performance in general-purpose microprocessors and digital signal processors (DSPs) has made the ability to perform multiple computations per cycle an essential feature of the architecture. Two common approaches to the execution of multiple computations per cycle used in modern microprocessors include Instruction-Level Parallelism (ILP) and Data-Level Parallelism (DLP).
Instruction-Level parallelism occurs at the operation level when two or more operations are data-independent from one another and may be executed concurrently. Data-level parallelism occurs when the same operation is executed on each member of a set of data.
A common way to exploit the data-level parallelism is to implement a Single Instruction Multiple Data (SIMD) Architecture. Here, single operations are specified in the instruction stream, but each operation is performed on multiple data elements. For the general SIMD case, these data elements may come from, and be written back to, disjoint locations. Current SIMD implementations (such as IBM VMX™ or Intel MMX™), however, do not allow this level of data flexibility. Instead, multiple data elements for SIMD operations are packed into a single register, often called a SIMD vector register.
Each instruction causes an operation to be performed on all elements in its source registers, and there is only one input data stream. On the other hand, an indirect-SIMD architecture, (such as the one described in J. Moreno et. al. “An innovative low-power high-performance programmable signal processor for digital communications”, IBM Journal of Research and Development, volume 47, number 2/3, 2003 pp. 299-326), provides access to disjoint data values via register pointers.
Rather than explicitly specifying vector elements in the SIMD instruction word, indirect-SIMD instructions have vector pointer source and destination fields, wherein each vector pointer specifies multiple indices. Data elements are accessed indirectly through statically specified pointers, and physical vectors are composed at execution-time based upon dynamic values in vector pointer registers.
The indirect access to the register file provides flexibility for data manipulation. For example, instead of moving data from one location in the register file to another, it is sufficient to redirect the corresponding register pointer.
In SIMD engines, the indirect access to the register file allows the programmer to specify a vector of several elements that do not necessarily reside in contiguous locations in the register file. However, the application of the indirect register file access mechanism is not limited to SIMD architectures. It also allows accessing register files with a large, and even variable number of entries, using less than log 2(N) bits in the instruction word to specify the operands, which may be a useful feature for either SIMD or scalar engines.
The indirect register file access mechanism has been disclosed in the following documents: U.S. Pat. Nos., 6,687,808, 6,052,766, 5,974,524, 5,890,222, 3,946,366, and described in papers by J. Moreno at. al., “An innovative low-power high-performance programmable signal processor for digital communications”, IBM Journal of Research and Development, volume 47, number 2/3, 2003 pp. 299-326) and H. Hunter, “A New Look at Exploiting Data Parallelism in Embedded Systems”, CASES, 2003.
Referring to FIG. 1, a prior art pipeline 10 of a processor with the indirect register file access is shown. A front end 12 of the pipeline includes instruction storage access and instruction decode with optional branch prediction. Following the front end 12 is an optional stage 14 where instructions are checked for dependencies and other stall conditions. This stage 14 may not be present in exposed pipeline processors, where it is the programmer's responsibility to resolve any stall conditions. At an issue stage 16, instructions ready for execution are forwarded to the appropriate execution engines for execution. The execution engine(s) provides pointer register file 18 (or a single pointer register) access, to read (or generate) one or more indices for read and write operands for all instructions issued in the same cycle. In other words, the execution engines do a mapping of the register pointer value to a physical register, and the contents of the physical register are used for the operation.
Then, the read indices read from the pointer file 18 are used to access a register file 20 for instruction operands, and the write indices are used to write the results back into the register file 20.
A set of pointer functional units (FUs) 24 is provided to execute instructions updating a (or at least one) pointer register (or multiple pointer registers) in the pointer register file 18. Various forms of pointer update instructions are described in the prior art, including incrementing pointers using a specific stride and/or using modulo arithmetic. Pointer registers 18 can also be updated by regular functional units 22, including, for example, a memory unit, or data transfer from the register file 20. In one example, vector pointers can be automatically updated to implement a circular addressing within a range of the register file.
One deficiency of the prior art implementation of the indirect register access mechanism is that no checking is performed for register dependencies between instructions (that is, dependencies through registers in the register file 20). These dependencies cannot be checked before the pointers are accessed, because the values of indexes to the register file 20 are not known at the dependence checking stage, and different pointers may point to the same entry in the register file (i.e., aliasing problem).
In the prior art, it is the responsibility of the programmer or compiler to schedule instructions in such a way that there are no register dependencies between instructions.
Therefore, a need exists for a system and method for execution of register pointer instructions, which provides flexibility to the programmer and avoids the aliasing problems of the prior art.